Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/rreq/rreq-minutes-90may.txt

Text File | 1993-02-17 | 11KB | 320 lines

CURRENT_MEETING_REPORT_


Reported by Vince Fuller/Stanford and Philip Almquist/ Consultant

Minutes:  Tuesday, 1-May (AM)


   o TOS routing

      -  Two aspects - internal queue handling vs.  next hop choice
          * RREQ document deals primarily with later (external behavior)
      -  Number of bits:  3 currently defined for TOS, 2 other ``spare''
         bits
          * does router need to know what bits mean or can it just match
            against information available via routing protocols?
          * is TOS a hint or a requirement (more discussion later) -
            hint implies it is safe to ignore extra bits for now
          * issue:  other groups may want to use those two bits for
            other things
          * requirement:  all routers must make the same routing choices
            regarding TOS and all must implement TOS (but not all
            protocols will use) to prevent routing loops (Chair's
            statement)
          * issue:  may have to change routing protocols if the number
            of bits changes (tough)
          * quote:  ``keep your paws off those two bits'' - JNC, Area
            Director
          * DECISION: use 3 bits (problem made moot by above quote)

   o TOS semantics:

      -  hint philosophy:  deliver packets to default TOS if no match
         exists
      -  requirement philosophy:  drop packets if no TOS match exists
         (editors note:  a very long and heated discussion of these
         differing philosophies consumed most of the first part of this
         session)
      -  TOS unreachable ICMP message for "requirement" case
      -  Proteon OSPF implementation allows per-TOS metric setting on
         lines; setting to infinity and dropping on no TOS match allows
         some small amount of policy control over line usage
      -  problem:  handling of TOS unreachable message is undefined
      -  problem:  won't work if host ignores TOS unreachables (or
         falls-back automatically to default TOS)
      -  problem:  TOS bits are not defined absolutely (i.e.  in bps,
         etc.)
      -  suggestion (Satz):  two sides write up their cases; include
         both in draft document for further review (any takers?)
      -  idea:  use one of the "unused" bits to specify hint/required
         TOS
      -  Milo believes looping can occur if TOS is treated as a hint -
         need specific scenarios

                                   1






o Fragmentation

   -  Review of each option outlined in draft text:
       * option 1:  no longer needed by MTU discovery
       * option 3:  invalid, since 576 is NOT the minimum required
         MTU size
   -  if anyone has empirical evidence of a good way to do it, them
      document should discuss it; otherwise, defer to IP RFC
       * action:  talk to Jeff Mogul and Van Jacobson about their
         experiments

o Reassembly

   -  Router MUST reassemble packets destined to itself (i.e.  ICMP
      messages)
       * router is acting as host in this case, must follow HR
       * HR says must reassemble max of 576 bytes or connected
         interface MTUs
   -  Router MUST NOT reassemble packets that are forwarded
       * reassembly not possible if multiple paths exist, etc.  etc.
   -  Multicast handling
      Minimal discussion.  Steve Deering (``Mr.  Multicast'')
      volunteered to write some draft text

o TTL

   -  Long discussion about schizophrenic use of TTL as time AND hop
      count
       * TCP makes assumptions about real time of packet life vs.
         TTL handling (problem can occur with sequent number
         wraparound)
       * no implementors expect to implement use of TTL as time (fact
         of life)
       * deprecate ``SHOULD'' to ``MAY'' for decrementing TTL by time
       * include discussion of why this should be done (what TCP
         expects, etc)
   -  Handling of TTL boundary conditions:
       * TTL 0 - router MUST NOT drop packets to itself on TTL = 0
         (HR sez)
       * router MUST NOT ever send a packet with TTL = 0 (ditto)
       * router SHOULD return ICMP time exceeded if it decrements TTL
         to 0
       * router MUST NOT ``pre-discard'' packets with TTL > 0 even if
         it knows (via link-state routing, for example) how many hops
         a destination is (it breaks ``traceroute'' to do so and
         doesn't really gain much)
       * should there be some discussion of ``traceroute's''
         expectations?



                                2






Minutes:  Tuesday, 1-May (PM)

A review of writing assignments/document sections was done The following
(mostly un-written) sections were worthy of mention (mainly because no
one is doing anything about them):

7.  Routing protocols - RIP, EGP, BGP (Yakov Rekhter/IBM), OSPF

8.  Network Management Protocols - SNMP (Steve Willis/Wellfleet),
CMIP/CMOT

9.  Administrative and Policy controls, including:  filters (both
traffic and routing info), interchange between EGP's and IGP's,
preference of routes by [protocol, neighbor, network number, etc.],
conditions for default generation, etc.  (subcommittee formed and had
preliminary discussion over lunch - included Steve Willis/Wellfleet,
Philip Almquist/Consultant/Stanford, Vince Fuller/Stanford/BARRNet,
Michael Reilly/DEC, and one or two others forgotten by the editor --
they and others interested in these issues (Milo, Jeff?)  should get in
touch with the Chair ASAP)

10.  Initialization, operation, management

Appendix A - Internet-specific requirements

Appendix B - Requirements for specific uses (i.e.  regional network)


   o Multicast

      -  forwarding of multicasts is not yet required
      -  router SHOULD perform host multicast functions (per RFC1112 and
         HR)
      -  router MUST NOT pass ``letter-bomb'' multicasts (as target of
         source route)
      -  record route doesn't present a problem (according to Steve D.)
      -  multicasts should not be used as an hop in a source route
         either

   o TOS, take 2 (Yakov had a few things to say)

      -  in current Internet, virtually no use (according to NSFNet
         statistics)
      -  chicken and egg problem (Steve D.)
      -  3 bits are too coarse to be useful for policy control
      -  all routers in AS (at least) must make same routing decision on
         TOS in order to prevent loops
          * what about for paths through multiple AS's?
          * what if AS's are multi-homed?
      -  how to use in presence of sources (protocols) of routing
         information?
          * use to prefer protocol if it has exact TOS match?

                                   3






   -  opinion:  TOS 0 is default - must always exist and is used if
      no exact match
   -  opinion:  forbid setting of multiple TOS bits (``Christmas
      tree'') - enforce by treating as treating as TOS 0 (?)
   -  no definite conclusion (no surprise here!)

o Broadcast handling

   -  Directed broadcasts
       * routers MUST support, MAY provide knob to disable
       * justification:  widely used, part of IP architecture
   -  All-subnets broadcast
       * current behavior:  only sent to first subnet seen
       * Chair will make case to IESG to make it an obsolete part of
         the IP architecture (by creating a successor to RFC922)
       * consider as a SHOULD NOT - may support, but MUST provide
         knob which defaults behavior to disabled

o IP options

   -  Record route - MAY in HR, specify as MUST in RREQ
   -  Timestamp - ditto
       * long discussion about when during packet processing the
         timestamp should be added - no conclusion
       * document should state that when it happens is not defined
         and will be implementation-dependent
       * Yakov (opinion):  all routers should do timestamp at same
         point in packet processing - not much agreement from rest of
         WG
   -  Option insertion by routers
       * security option must be inserted, so it MUST be allowed
         (RFC1108)
       * what if no option space available - Martin Gross/DCA will
         address
       * are there other options that need to be inserted?
   -  non-understood options - MUST be passed unchanged
   -  source route - only one source route option may exist

o Precedence

   -  OSPF mandates that routers set precedence to Internet Control
   -  BGP - ditto
   -  issue:  may be political problems with this
   -  what about network management traffic?
   -  DCA group is working on paper describing scheme

o Martian address filtering
  MUST provide functionality and provide switch to enable/disable
  (long discussion ensued about performance impact of making it
  strictly a MUST)
o What's next?

   -  video-conference will take place in June (tentatively, Monday,
      June 11th)

                                4






-  Internet-Draft is expected after August IETF



                             5






ATTENDEES

    Richard Smith             [e-mail]
    David Waitzman            [e-mail]
    John Wobus                [e-mail]
    Pablo Brenner
    Jonathan Wenocur          [e-mail]
    Dave Forster
    Steve Willis              [e-mail]
    Michael Reilly            [e-mail]
    Martin Gross              [e-mail]
    Peter Vinsel              farcomp![e-mail]
    Stev Knowles              [e-mail]
    Vince Fuller              [e-mail]
    Frank Kastenholz          [e-mail]
    John Moy                  [e-mail]
    Roxanne Streeter          [e-mail]
    David Miller              [e-mail]
    Douglas Bagnall           [e-mail]
    Walt Wimer                [e-mail]
    Kanchei Loa               [e-mail]
    Yoni Malachi              [e-mail]
    Karen Frisa               [e-mail]
    Stepanie Price            price@mcvax!ucsbcsl.edu
    Stan Froyd                [e-mail]
    John Cavanaugh            [e-mail]
    John Veizades             [e-mail]
    Steven Senum              [e-mail]
    Kannan Varadhan           [e-mail]
    Steven Bruniars
    Paul Tsuchiya             [e-mail]
    Kathy Huber               [e-mail]
    Steve Deering             [e-mail]
    Greg Satz                 [e-mail]
    Curtis Cox                [e-mail]
    Milo Medin                [e-mail]
    Phil Karn                 [e-mail]
    Y Wang
    Keith Hogan               [e-mail]
    Richard Woundy            [e-mail]
    Mary Youssef              [e-mail]
    Jim Sheridan              [e-mail]
    Dino Farinacci            [e-mail]
    Steve Storch              [e-mail]
    Phil Park                 [e-mail]
    Sze-Ying Wuu              [e-mail]
    Tim Hunter                [e-mail]
    Steve Hubert              [e-mail]
    John Vollbrecht           [e-mail]
    Joel Replogle             [e-mail]
    Paul Pomes                [e-mail]
    Drew Perkins              [e-mail]
    Stephanie Price           price@cmcvax!uscbcsl.edu


                                   6








7